Mass transit fare processing system

ABSTRACT

An implementation of a system and method for using existing identification token infrastructures for mass transit fare product entitlement and payment is provided. The system and method make use of tokens—usually issued by a third party—for identification purposes and optionally for settlement purposes. The system does not store information on the tokens and instead maintains access control data (i.e., “white” and “black” lists). This implementation differs from known systems that require specially issued credit cards that have dedicated mass transit functionality.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit under 35 U.S.C. 119(e) of U.S.Provisional Application 61/484,219 (Attorney Docket SPE002 PV), entitled“Mass Transit Fare Processing System” and filed May 10, 2011, which isincorporated herein by reference and assigned to the same assignee asthe present application. This application is also a continuation-in-partand claims the benefit under 35 U.S.C. 120 of co-pending U.S.spplication Ser. No. 12/511,037 (Attorney Docket SPE003 US), entitled“Public transit system fare processor for transfers” and filed Jul. 28,2009, which is a continuation-in-part of U.S. Pat. No. 7,566,003(application Ser. No. 11/838,499 entitled “Learning Fare CollectionSystem for Mass Transit” filed Aug. 14, 2007, Attorney Docket SPE006US), and a continuation-in-part of U.S. Pat. No. 7,568,617 (applicationSer. No. 11/668,456 also entitled “Learning Fare Collection System forMass Transit” filed Jan. 29, 2007, Attorney Docket SPE005 US), whicheach claims the benefit under 35 U.S.C. 119(e) from U.S. ProvisionalApplication 60/869,112, filed Dec. 7, 2006 (Attorney Docket SPE005 PV),each of which are incorporated herein by reference and assigned to thesame assignee as the present application.

BACKGROUND OF THE INVENTION

1.Field of the Invention

The invention relates generally to public transit system access and morespecifically to enabling a full set of mass-transit fare-productswithout the need to store information on the identification tokens.

2. Background of the Invention

Fare collection in mass transit has traditionally relied on mass transitagencies issuing scrip. A “scrip ticket” is used to describe paper moneybeing used for, e.g., mass transit rides in lieu of taking money atthose rides. Originally in tangible form like coinage, the same systemwas later translated to the electronic domain as a “virtual scrip.” Thevirtual scrip was first stored in magnetic memory, later in electricalmemory, sometimes connected to a microprocessor, such as in the case ofso called smart cards.

The advent of virtual scrip brought with it the use of the storagemedium to store not just scrip or a currency balance, but to storeentitlement on the storage medium (in which case it may be called “faremedia”). Such an entitlement might be the right to ride free of charge,or free of additional charge, for a specified time (e.g., a monthlypass), or the right to a reduced fare (e.g. a senior citizen pass).

However, such electronic fare media comes at a significant financialcost for transit agencies; not only is production and issuance ofvirtual scrip and other fare media very expensive, fraud risk is anadditional burden in this model.

Independently of the above development, the recent years have broughtthe ubiquity contactless credit cards and contactless debit cards, aswell as first attempts of implementing wireless payment oridentification protocols using mobile phones.

A need thus exists to enable mass transit agencies to give up issuingfare media and make use of existing semi-public infrastructures ofidentification tokens, such as the credit and debit card networks, whereissuers take on the cost of production, issuance and where the networkstake on much of the fraud risk.

SUMMARY

An implementation of a system and method for using existingidentification token infrastructures for mass transit fare productentitlement and payment is provided. The system and method make use oftokens—usually issued by a third party—for identification purposes andoptionally for settlement purposes. The system does not storeinformation on the tokens and instead maintains access control data(i.e., “white” and “black” lists). This implementation differs fromknown systems that require specially issued credit cards that havededicated mass transit functionality.

Embodiments of the present invention include a fare processor (a transitsystem rules processor) to maintain access control lists and account forand settle fare payments.

Some embodiments of the present invention provide for a fare processor,the fare processor comprising: at least one processor; a first interfacecoupled to the at least one processor and coupled to receive a pluralityof presentation records from the at least one public transit system;memory coupled to the at least one processor, wherein the memory isconfigured to hold the received plurality of presentation records; farerules; and transit account data comprising an account state for aplurality of transit accounts; and a second interface coupled to the atleast one processor and coupled to communicate to a payment gateway tosettle the plurality of transit accounts; wherein the at least oneprocessor is configured to apply the fare rules to the receivedplurality of presentation records.

Some embodiments of the present invention provide for a method forgating entry into a first transit system, the method comprising:receiving a set of records, wherein each of the records includes anindex representative of an individual token, and wherein the set ofrecords includes a set of records representing black-listed tokenswherein a black-listed token will be denied access to the first transitsystem; sequentially reading, at a token terminal, and processing tokendata from a plurality of tokens, wherein a first token of the pluralityof tokens is issued by a first issuer and a second token of theplurality of tokens is issued by a second issuer separate and distinctfrom the first issuer, and wherein the first and second issuers areseparate from the first transit system; processing a third tokencomprising: (a) reading, at the token terminal, token data from thethird token; (b) determining an index representative of the third token;(c) searching for the index representative of the third token in the setof records to determine a status of the third token; (d) setting thestatus of the third token to indicate the third token is an unknowntoken; and (e) allowing access into the first transit system andentering, to a transaction history database, an indication of accessinto the first transit system by a holder of the third token; providing,to a processing system, entries from the transaction history databasefor remote determination of a transaction amount for each entry; andreceiving an update to the set of records.

Some embodiments of the present invention provide for a method forauthorizing a bankcard transaction, the method comprising: downloadingtwo sets of records, each record comprising at least a bankcardidentifier, the first set representing known invalid bankcards, thesecond set representing known valid bankcards. receiving a firstauthorization request, referencing a first bankcard checking if thefirst bankcard matches a known invalid card denying the firstauthorization request, if the first bankcard matches a known invalidcard receiving a second authorization request, referencing a secondbankcard, the request comprising at least the identifier of a secondbankcard checking if the second bankcard matches a known invalid cardchecking if the second bankcard matches a known valid card approving thesecond authorization request, if the first bankcard does not match anyknown invalid cards, and matches a known valid card.

Some embodiments of the present invention provide for a method forcontrolling access to a transit network by maintaining a black list ofidentifying tokens, the method comprising: granting a potential rideraccess to a transit system upon presentation of an identifying token,comprising: reading a first set of token data from a first identifyingtoken using a token reader; computing a first token identifier from thetoken data; checking the first token against a black list in memory,using the first token identifier; and allowing access to the transitnetwork, if the first token is not black listed; denying a potentialrider access to the transit system upon presentation of an identifyingtoken, comprising reading a second set of token data from a secondidentifying token, using a token reader; computing a second tokenidentifier from the token data; checking the second token against ablack list in memory, using the second token identifier; and denyingaccess to the transit network, if the second token is black listed;removing a third identifying token from the black list after itsoutstanding balance is paid, comprising: successfully charging a paymentaccount associated with the third identifying token; and removing thethird user token from the black list; and adding a fourth identifyingtoken to the black list if the outstanding balance remains unpaid,comprising: unsuccessfully charging one or more a payment accountsassociated with the fourth identifying token; and adding the fourthidentifying token to the black list.

Some embodiments of the present invention provide for a fare processingsystem associated with a set of public transit systems, the processingsystem comprising: a first interface to receive a plurality ofpresentation records from at least one of the set of public transitsystems record memory to hold received presentation records rule memoryto hold fare rules account memory to store the state of one or moretransit accounts a second interface connected to a payment gateway tosettle the one or more transit accounts one or more processors, coupledto the first and second interfaces and to the record memory, rule memoryand account memory, to apply the fare rules held in the rule memory tothe presentations records held in the presentation record memory.

These and other aspects, features and advantages of the invention willbe apparent from reference to the embodiments described hereinafter.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the invention will be described, by way of example only,with reference to the drawings.

FIG. 1 shows a transit system network 10 with an associated fareprocessing system 300 (also called a fare processor or transit systemrules processor) and various components in accordance with the presentinvention.

FIG. 2A shows a bankcard terminal 200, in accordance with embodiments ofthe present invention.

FIG. 2B shows a fare processing system 300, in accordance withembodiments of the present invention.

FIG. 3 illustrates a state diagram, in accordance with embodiments ofthe present invention.

FIG. 4 represents a flowchart implementation for operations in abankcard terminal 200, in accordance with embodiments of the presentinvention.

FIG. 5 shows the minimal steps required to conduct a bankcardtransaction in a transit context where a bankcard 100 transmits bankcarddata 110 to bankcard terminal 200.

FIG. 6 shows an exemplary instance of a bankcard verification system600.

FIG. 7 shows an embodiment of the invention, where authorizations arehandled by an authorization proxy 140 which may consult with bankcardinfrastructure 600.

FIG. 8 shows another flow, where the proxy 140 delegates theauthorization 120 and passes it on verbatim.

FIG. 9 depicts a bankcard verification proxy 610 moved closer tobankcard terminal 200 to improve performance and reliability, accordingto some instances of the present invention.

FIG. 10 shows a bankcard verification proxy 610 as part of bankcardterminal 200, to further improve performance and reliability accordingto some instances of the present invention.

FIG. 11 shows a bankcard verification proxy 610 as a component of fareprocessing system 300, according to yet other instances of the presentinvention.

FIG. 12 shows a bankcard verification proxy 610 being used only for somecard networks, in accordance with some instances of the presentinvention. Additionally, it shows the use of a transit switch, whichacts as a bankcard verification proxy.

FIG. 13 depicts a bankcard verification proxy 610 and fare processingsystem 300 draw upon access control lists (ACL) that are maintained byinterpreting data from various sources, according to some embodiments ofthe present invention.

FIG. 14 details a transit account ACL 230A containing transit accountrecord 700, according to some instances of the present invention.

FIG. 15 details a bankcard ACL 230B containing a bankcard record 760.

FIG. 16 shows the invention's response to a presented user token 105,according to some embodiments of the present invention.

FIG. 17 shows the response to a presently unknown or black listed usertoken.

FIGS. 18A, 18B and 18C show the response to the presentation of anunknown or black listed bankcard 100, as implemented in some embodimentsof the invention.

FIG. 19 shows the response to a known valid bankcard.

FIG. 20 shows the response to a known valid user token.

FIG. 21 shows the sequence of events making up a transfer transaction,where a plurality of rides are accounted for as a single ride..

FIGS. 22A and 22B show two alternative reactions when fare processor 300determines (880) that it cannot communicate with either the bankcardverification system 600 nor proxy 610.

FIGS. 23A and 23B show two decision trees, implemented in someembodiments of the present invention.

FIG. 24 shows how the fare processor 300 settles balances of transitaccounts it maintains.

FIGS. 25 and 27 represent flowchart implementations for operations in aprocessing system, in accordance with embodiments of the presentinvention.

FIG. 26 illustrates the process of registering a token and paymentmethod for a fare product.

FIG. 28 shows additional detail of a presentation record processor(rules processor), in accordance with embodiments of the presentinvention.

DETAILED DESCRIPTION OF THE INVENTION

In the following description, reference is made to the accompanyingdrawings, which illustrate several embodiments of the present invention.It is understood that other embodiments may be utilized and mechanical,compositional, structural, electrical, and operational changes may bemade without departing from the spirit and scope of the presentdisclosure. The following detailed description is not to be taken in alimiting sense. Furthermore, some portions of the detailed descriptionthat follows are presented in terms of procedures, steps, logic blocks,processing, and other symbolic representations of operations on databits that can be performed in electronic circuitry or on computermemory. A procedure, computer executed step, logic block, process, etc.,are here conceived to be a self-consistent sequence of steps orinstructions leading to a desired result. The steps are those utilizingphysical manipulations of physical quantities. These quantities can takethe form of electrical, magnetic, or radio signals capable of beingstored, transferred, combined, compared, and otherwise manipulated inelectronic circuitry or in a computer system. These signals may bereferred to at times as bits, values, elements, symbols, characters,terms, numbers, or the like. Each step may be performed by hardware,software, firmware, or combinations thereof.

Hereinafter, a bankcard, such as a credit card or a debit card, is apayment token that may be linked to a bank account or credit line.Bankcards include cards and tokens in any of a number of form factors. Abankcard may be dimensioned in accordance with ISO 7810/7813 ID1 (about3.375″×2.125″×0.0030″, commonly known as “Credit Card Format”).Alternatively, a bankcard may take other forms. A bankcard may take theform of a key fob (e.g., as issued by Speedpass™) or wristband.Alternatively, the bankcard may be embedded into, integrated with or beemulated by a mobile phone or other handheld device. A bankcard includesmemory to hold an identifier used to uniquely identify an account forbilling. The memory may be in the form of a magnetic stripe and/or maybe attached to circuitry, which may be in accordance to ISO 7816. Abankcard may include or be integrated with contactless circuitry, suchas ISO 14443. In some embodiments, a bankcard includes a token issued bya third party that is not a transit agency, such as a bank, creditunion, a government agency (issuing a state driver's license or DMVissued identification card, federal government issued passport and/orother government issued ID).

Hereinafter, a user token, such a bankcard or government ID, issomething that allows a rider to be identify with a certainty that issufficient for mass transit fare collection. In some embodiments of theinvention, a token is not limited to physical devices, but isintangible, such as a biometric trait.

FIG. 1 shows a transit system network 10 with an associated fareprocessing system 300 (also called a fare processor or transit systemrules processor) and various components in accordance with the presentinvention. Transit System network 10 includes bankcard terminals 200.Bankcard terminals 200 provide a front-end interface to bankcards. Abankcard terminal 200A may take the form of a turnstile at a gate in asubway or heavy rail system. Alternatively, a bankcard terminal 200A maybe used on a transit system incorporating a self-policing or honorsystem (i.e., a passenger may enter into the transit system withoutbeing physically gated by a turnstile; the passenger voluntarilyprovides his or her bankcard to the to the bankcard terminal 200A; inthis case, gating may simply be provided by an audible and/or visibleindicator, whether or not the passenger has the right to enter). Abankcard terminal 200B may be integrated into a bill or coin collectionterminal (often called a fare box) on a bus. A bankcard terminal 200Cmay be a handheld device used by a conductor in a train, to collectpayment and/or to validate the previous purchase of a fare product.Collecting information from each of the bankcard terminals 200 is a fareprocessing system 300. Fare processing system 300 may interface to abankcard terminal via a wired connection or a wireless connection. Theinterface may provide a constant connection, such as a dedicatedcommunication line between a turnstile at a gate and a fare processingsystem 300. Alternatively, the interface may provide an intermittentconnection, such as a wireless connection. In some cases, a connectionbetween a bankcard terminal 200 and a fare processing system 300 may bemade after a long period of service. For example, at the end of a day,the connection may be made between a bankcard terminal 200B in a buswhen the bus retires to the garage, or when a handheld bankcard terminal200C is brought back to the station.

Fare processing system 300 may also include one or more interface to aregistration system 500. Registration system 500 provides a back-endinterface to bankcards. A bankcard holder may register a bankcard withfare processing system 300 via a website, using an interactive voiceresponse system (IVR), at an interactive electronic kiosk, or using avending machine by supplying registration data either manually and/or byenabling the registration system 500 to read registration data from thebankcard. Alternatively, a proxy of the bankcard holder, such as thebankcard issuer, may register bankcards with fare processing system 300on behalf of the holder. Such a proxy registration may be for anindividual card or in bulk for a plurality of cards. Registration datamay include bankcard data contained on the card, such as cardholdername, bankcard number or expiration data, and/or bankcard meta-data,such as the billing address or other cardholder data. Registration datatransmitted during a proxy registration may include data that is notreadily available to the holder, such as an alias bankcard number thatis transmitted over the card's wireless interface instead of the actualbankcard number, or such as a cryptographic key and/or shared secret,used to authenticate the bankcard. A proxy may additionally transmitregistration data programmatically, via remote procedure calls, usingprotocols such as REST or SOAP, or by manually or automaticallytransmitting files to the registration system or directly to the fareprocessing system 300. In some embodiments of the invention, holder andissuer both supply bankcard data and/or meta-data to registration system500 and/or fare processing system 300. In some embodiments of theinvention, registration system 500 may be part of fare processing system300.

Fare processing system 300 may also include one or more interfaces to abankcard verification system 600. The bankcard verification system willverify whether a bankcard is currently a valid bankcard and/or if it islikely to be good for a given amount of money. In some embodiments ofthis invention, the bankcard verification system is nothing more than aninterface to a standard bankcard authorization system, ultimatelyutilizing a switch to connect to settlement and clearing networks usedby debit and credit card companies. In other embodiments, the bankcardverification system is capable of verifying cards independently of aconnection to clearing and settlement networks. Because issues ofcontrol over the card verification system relate closely to security andliability, in particular when card data is stored, in some instances ofthe invention, bankcard verification system 600 is under the control ofan acquirer, while in others it may be under the control of a processor(processor in the sense of a 3rd party card processing company) and inyet another instance, it may be under the control of a transit network,and finally it may be under the control of a card network.

FIG. 2A shows a bankcard terminal 200, in accordance with embodiments ofthe present invention. Bankcard terminal 200 includes at least onebankcard reader 210, a bankcard terminal processor 220, a firstinterface 250 to a processing system 300, and a second interface 260 toassist in gating access. In some instance of the present invention, thebankcard terminal has memory to hold a set of bankcard records 230 andaccess history 240. In some embodiments, a single bankcard terminal 200has multiple bankcard readers 210. For instance could a single terminalhandle an entire station, allowing for a reduction in cost at theexpense of reliability. In some instances of the invention, bankcardreader 210 reads user tokens 105, which are not bankcards but simplysomething uniquely identifiable, such as government issued IDs,including RFID enabled driver's licenses, or biometrics of the riderattempting to gain access.

In some embodiments, bankcard reader 210 provides a physical,electrical, electromagnetic, optical, magnetic, and/or radio frequency(RF) interface to bankcards 100. Bankcard reader 210 may be a receiverwithout a transmitter or may include both a receiver and a transmitterto communicate with a bankcard 100. A bankcard may transmit bankcarddata including: (1) a cardholder's name; (2) a bankcard number (e.g., aPAN as defined in ISO/IEC 7812); (3) an expiration date; (4) securitydata (e.g., the result of a cryptographic operation based on one or morecryptographic keys stored in the card's memory); (5) issuer privatedata; and/or (6) records or summaries of past transactions. Bankcardsare not limited to what is commonly known as a credit card's physicalembodiment.

In some embodiments, bankcard reader 210 simply reads data from bankcard100 as bankcard 100 passes by it. In some embodiments, bankcard reader210 transmits a signal to bankcard 100 to access bankcard data. Bankcardreader forwards selective bankcard data or all bankcard data received tobankcard terminal processor 220. In some embodiments, bankcard readeradditionally transmits to bankcard terminal processor 220 communicationmeta-data resulting from communication with the bankcard, such asprotocol data.

Bankcard terminal Processor 220 includes a first interface 250 to a fareprocessing system 300 and a second interface 260 to assist in gatingaccess, as well as an interface to memory. Bankcard terminal processormay be implemented with a microcontroller, a microprocessor and/or otherlogic circuitry. In some embodiments of the present invention, thebankcard terminal processor 220 reads, writes and updates data in memoryrepresenting a set of bankcard records 230, which contains a set ofknown bankcards, and an optional access history 240, which keeps ahistory of bankcards presented to bankcard terminal 200 and may be usedfor billing. In other embodiments of the invention, the set of bankcardrecords 230 and/or access history 240 may be located elsewhere, forinstance with or in fare processing system 300 or bankcard verificationsystem 600, described in further detail below. The set of bankcardrecords 230 and access history 240 may be in the form of one or moresequential lists, tree structures, other sorted data structures and/ordatabases, which may be indexed or searchable by one or more anidentifiers such as a hash value or the identifier of a bank card, suchas a PAN or a PAN alias. The set of bankcard records 230 may bepresorted for faster subsequent searching. The set of bankcard records230, access history 240 and identifiers are described in more detailbelow.

FIG. 2B shows a fare processing system 300, in accordance withembodiments of the present invention. Fare processing system 300 isassociated with one or more transit systems and may be part of orseparate from the transit systems. Fare processing system 300 includes afirst interface 310 to communicate with one or more bankcard terminals200, a processor 320, memory, a second interface 340 to communicate witha bankcard verification system, and a third interface 350 to communicatewith a bankcard registration system.

Processor 320 is coupled to and communicates with first interface 310,second interface 340 and third interface 350, respectively. Processor320 is also coupled to memory and manipulates a set of known bankcardrecords 330 held in the memory. The set of known bankcard records 330may contain bankcard data (such as a bankcard number, usually a PANand/or a PAN alias as described below) or one or more hash valuescomputed from the bankcard data. Processor 320 may be implemented with amicrocontroller, a microprocessor and/or other logic circuitry.

The set of known bankcard records 330 contains an identifier of eachbankcard in the set. The bankcard 100 may be one that was previouslypresented by a respective holder of the bankcard 100 to fare processingsystem 300 and verified by fare processing system 300. A presentationmay be by way of a physical presentation by the holder at a bankcardterminal 200 at a gate or entrance of a transit system. Alternatively,the presentation may be by way of registering the bankcard 100 over thetelephone, for example, using an IVR system, or by way of registeringusing the Internet, for example, using a web browser. Alternatively, thepresentation may be by a bank or other financial institution enablingthe bankcard by communicating with processor 320. Such a financialinstitution may provide multiple presentations to fare processing system300 individually or in a batch process.

At a bankcard terminal, bankcard data received via a magnetic stripe maydiffer from that received over the air through an RF connection, whichmay differ still from bankcard data received via a registration system.For example, bankcard data may contain a Primary Account Number (PAN),which is typically a 15-digit to 16-digit numeric code embossed on theface side of a bankcard, and which is also encoded in the magneticstripe. PAN is further defined in ISO/IEC 7811 and ISO/IEC 7812. The PANstandard allows up to 19 digits. The PAN standard allows for three maincomponents in the form nnnn nndd dddd ddds where: (1) nnnn nn is theIssuer Identification Number (IIN) (typically six digits); (2) dd ddddddd is the NIH ID number or individual account identification (IAI) (upto twelve digits) without the check digit; and (3) s is the ISO/EIC7812-1 check digit. A bankcard having a wireless chip may be coded witha different identifying number than the PAN. For example, when abankcard communicates with an RF reader, it will send an alias or ghostof the PAN rather than the PAN itself. The PAN alias may need to bemapped to a PAN for further processing. Not all bankcards are in fullcompliance with aforementioned standards (e.g., some do not use a checkdigit). Some embodiments of the present invention operate with bankcardscompliant with these PAN ISO/IEC standards while other embodimentsoperate with non-compliant bankcards not compliant to the PAN ISO/IECstandards. Still other embodiments of the present invention operate witha family of compliant and non-compliant bankcards.

If a bankcard is expected to provide different identifying data (e.g.,PAN alias) rather than the credit card number (e.g., PAN), the bankcardterminal 200, fare processing system 300, verification system or thelike will provide a translation between the alias PAN and the PAN. Insome cases, the set of bankcard records 230 in the bankcard terminal 200contains a PAN, an alias PAN, a hash value based on the PAN, and/or ahash value based on the alias PAN. In some cases, the set of knownbankcard records 330 in the fare processing system 300 contains a PAN,an alias PAN, a hash value based on the PAN, and/or a hash value basedon the alias PAN.

As stated above, the set of bankcard records 230 may be presorted forfaster subsequent searching. For example, the set of bankcard records230 may be stored as a self-balancing tree. In some embodiments, abankcard identifier is determined using the Issuer Identification Number(IIN) and the individual account identification (IAI) without the checkdigit. The check digit is not included in the determined bankcardidentifier because it is simply a checksum value and does not provideany additional identification. In some embodiments, the determinedbankcard identifier includes the individual account identification (IAI)and the record is stored together with other determined bankcardidentifier having the same Issuer Identification Number (IIN). In theseembodiments, a first lookup will search for the IIN and a second lookupwill subsequently search for the IAI. In some embodiments, the IIN isused for the first search and a hash value is created and used for theIAI. In other embodiments, a first hash value is created for the IIN anda second hash value is created for the IAI. These embodiments providefor both compact storage and sufficient speed. Some embodiments requirethat the time between bankcard presentation by a cardholder and grantingor denying access be within 200 milliseconds. Therefore, a search of theset of bankcard records 230 should be complete within 200 milliseconds.

First interface 310, second interface 340 and third interface 350 mayshare a common physical interface, for example, the physical interfacemaybe an Ethernet connection to the Internet and/or an intranet. In thiscase, first interface 310, second interface 340 and third interface 350share a common physical interface but are logically three differentinterfaces. For example, first interface 310, second interface 340 andthird interface 350 may each have a unique socket identifier.

FIG. 3 illustrates a state diagram, in accordance with embodiments ofthe present invention. Bankcards may be considered to be in one of twoclassifications: an unknown bankcard 20 or a known bankcard 30. Anunknown bankcard 20 represents a bankcard that has not been presented bya respective holder of the bankcard. Thus, the set of bankcard records230 (in FIG. 2A) and the set of known bankcard records 330 (in FIG. 2B)will now have an identifier for the unknown bankcard 20.

When an unknown bankcard 20 is presented it becomes a known bankcard 30.A known bankcard 30 may also be considered to be in one of twoclassifications: a known valid bankcard 32 or a known invalid bankcard34. A known valid bankcard 32 represents a bankcard that has beenpresented by a respective holder of the bankcard as well as verifiedwith a bankcard verification system 600. A known invalid bankcard 34represents a bankcard that has been presented by a respective holder ofthe bankcard 100; however, verification with a bankcard verificationsystem 600 has failed in some respect. For example, bankcard terminal200 or fare processing system 300 was unable to communicate withbankcard verification system 600. Alternatively, bankcard terminal 200or fare processing system 300 communicated with bankcard verificationsystem 600, which indicated bankcard 100 is somehow the invalid for apurchase. A known valid bankcard 32 may transition to a known invalidbankcard 34, for example, if an attempt to clear and settle atransaction fails. Similarly, a known invalid bankcard 34 may transitionto a known valid bankcard 32, for example, if an attempt to verify or toclear and settle a transaction completes successfully.

FIG. 4 represents a flowchart implementation for operations in abankcard terminal 200, in accordance with embodiments of the presentinvention. In 401, a respective holder of a bankcard 100 presents thebankcard to a bankcard terminal 200 for access to a transit system.Bankcard terminal 200 reads, from the bankcard, bankcard data includinga bankcard identifier. Bankcard terminal 200 determines an identifier,such as a credit card number read from the bankcard data or by computinga hash value based on the bankcard identifier.

A bankcard terminal 200 may receive bankcard data from one or more ofseveral paths. First, a bankcard terminal 200 may receive bankcard datadirectly from a bankcard's magnetic stripe (e.g., a bankcard holder maypass a magnetic stripe of a bankcard 100 through a magnetic stripereader on the bankcard reader 210). Second, a bankcard terminal 200 mayreceive bankcard data via an RF connection between the bankcard terminal200 and the bankcard (e.g., a wireless chip in a bankcard 100 maycommunicate with a radio transceiver in a bankcard reader 210). Third, abankcard terminal 200 may receive bankcard data directly from electroniccontacts to a smart chip on the bankcard. Fourth, bankcard terminal 200may receive bankcard data from a fare processing system 300, whichpreviously received bankcard data from an external connection (e.g., IVRsystem, Internet/web interface, and/or financial institution and/or oneor more agents of financial institutions). After receiving andprocessing bankcard data received from a third interface 350 to aregistration system 500, the fare processing system 300 may sendbankcard data to a bankcard terminal 200 through its first interface310, second interface 340 and third interface 350.

A hash function may be used to compute a hash value from the bankcarddata. A hash function or hash algorithm is a reproducible method ofturning bankcard data into hash data that may serve as a digitalfingerprint of the bankcard data. The hash function may be considered tochop and mix (i.e., substitutes or transposes) the data to create such afingerprint. The fingerprint may be called hash sums, hash values, hashcodes or simply hashes. The hash computation may be based on acryptographic hash function. Broadly speaking, a cryptographic hashfunction behaves like a random function while still being deterministicand efficiently computable.

In 402, bankcard terminal 200 uses the determined identifier to tellwhether or not the bankcard is contained in a set of bankcard recordsand whether or not the bankcard is a known valid bankcard. In someembodiments of bankcard terminal 200 that have an interface to abankcard verification system 600, an attempt is made to verify thebankcard at 404. At 405, bankcard terminal 200 determines whether or notthe bankcard was successfully verified. At 406, if the bankcard wassuccessfully verified, the set of bankcard records 230 is updated withthe determined identifier for the currently presented bankcard. At 407,if the verification was unsuccessful, access is denied, for example bynot opening a gate and/or by activating an audio and/or visual indicatorto the bankcard holder and/or to a conductor. At 403, if the determinedidentifier was already in the set of bankcard records 230 as a knownvalid bankcard or was added to the set of bankcard records (at 406),access to the transit system is allowed, for example, by opening thegate and/or by activating an audio and/or visual indicator to thebankcard holder and/or to a conductor.

FIG. 5 shows the minimal steps required to conduct a bankcardtransaction in a transit context where a bankcard 100 transmits bankcarddata 110 to bankcard terminal 200. Bankcard data 110 may be all or asubset of the data contained on bankcard 100, and/or data computed onbankcard 100, such as data resulting from cryptographic operations orfrom the card holder interacting with the card, such as entering a PINor providing biometric data. In response to receiving bankcard data 110,bankcard terminal 200 passes bankcard data 115, which may be identicalto bankcard data 110, or may be computationally derived from bankcarddata 110, for instance an encrypted version of it, on to fare processingsystem 300. Depending on its programming and state, such as fare rulesand historic data associated with bankcard 100, fare processing system300 may create an authorization request 120 based on bankcard data 115to increase the likelihood that a fare balance due can later be settled.Authorization request 120 will be for specific amount of money,including very small amounts to simply ensure the validity of a card(thereby performing authentication only). Authorization request 120passes the virtual boundary between transit authority and financialnetwork and is received by bankcard verification system 600.

A system as illustrated in FIG. 5 is too slow for transit, sometimesrequiring more than 30 seconds just for the communications in thefinancial network domain, whereas the commonly accepted maximal durationfor a bankcard transaction in mass transit is 300 ms, dictated by thespeed by which travelers pass the transit gates during rush hour. Thepresent invention adds a verification proxy 610 that circumvents ordelays the use of bankcard verification system 600. In some embodimentsof the invention, the authorization proxy receives authorization request120 from fare processing system 300 and replies to the same withauthorization response 130, and in response to authorization request 120sends authorization request 140 to bankcard verification system 600 andreceives authorization responses 150 from the same.

FIG. 6 shows the topology of a bankcard infrastructure 600 to which afare processor is connected, in some embodiments of the presentinvention, for purposes of authenticating bankcards and/or receivingpayment from bankcard holders. An authorization request 120 thatoriginated at fare processor 300 (FIG. 5) flows from an Acquirer 640through a card network 650 until it reaches the card's issuer 660. Insome embodiments, e.g., where the Acquirer has principally the functionof an underwriter, fare processor 300 is connected directly to cardnetwork 650. The authorization response 150 then flows in the oppositedirection back to the fare processor. In some embodiments, theauthorization response will not originate at the card's issuer: insteadthe network issues a “stand-in” authorization, e.g., if the issuer isunreachable.

In FIG. 6, an exemplary instance of a bankcard verification system 600is shown. Merchants have traditionally been passing their data to anacquirer 640 (usually a bank), who will have the technology to routetransaction data, such as authorization request 120, to the correctpayment network 650. It is usually up to the payment network to routethe authorization request to the card issuer 660, although it isstandard practice for the network to stand in for the issuer undercertain conditions, such as communication failures. An authorizationresponse 150 will be passed back to the merchant, unless this isprevented by an exceptional condition, such as a communications error.

FIG. 7 shows an embodiment of the invention, where authorizations arehandled by an authorization proxy 140 which may consult with bankcardinfrastructure 600. One reasons for the described configuration is speed(authorizations from the issuer usually take seconds, authorizations atthe proxy milliseconds), which is of the essence in mass transit, wherebusy turnstiles can have traffic of 90 people per minute. Another reasonis that the proxy can have transit network specific informationavailable to it. The flow shown is for the case where the proxy 140 canmake an authorization by itself and in response sends a separateauthorization request into bankcard infrastructure 600.

This configuration is depicted in FIG. 7, which also indicates thepreferred geographical location of bankcard verification proxy 610 inthis configuration, namely at the transit authority, close to fareprocessing system 300 for best communication speed and reliability. Itshould be noted that geographic location does not necessarily implylegal ownership or liability for bankcard verification proxy 610; itwould usually be owned or operated by an acquirer or network. FIG. 8shows another flow, where the proxy 140 delegates the authorization 120and passes it on verbatim similar to FIG. 7.

FIG. 9 depicts a bankcard verification proxy 610 moved closer tobankcard terminal 200 to improve performance, according to in someinstances of the present invention. It then receives authorizationrequest 120 directly from bankcard terminal 200 and responds to the samewith an authorization response 130. Bankcard verification proxy 610 maysend it's authorization request 140 to bankcard verification system 600directly or via fare processing system 300 as shown in FIG. 9.Similarly, the authorization response 150 is received by bankcardverification proxy 610 directly or via fare processing system 300 asshown in FIG. 9.

FIG. 10 shows a bankcard verification proxy 610 as part of bankcardterminal 200, according to some instances of the present invention. Thearrangement provides the shortest possible path of communication betweenbankcard verification proxy 610 and bankcard terminal 200, and alsoridding the system of an important point of failure by decentralizingbankcard verification proxy 610. In this configuration, authorizationrequest 140 is sent to from bankcard terminal 200 to bankcardverification system 600 directly or via fare processing system 300.Likewise, the authorization response 150 is received by bankcardverification proxy 610 directly or via fare processing system 300. Sucha design requires that bankcard terminal 200 be particularly wellsecured, because it is more accessible than a server in a data center.For even better reliability, bankcard verification proxy 610 may bedistributed among several bankcard terminals.

FIG. 11 shows a bankcard verification proxy 610 as a component of fareprocessing system 300, according to yet other instances of the presentinvention. In this configuration, bankcard terminal 200 sendsauthorization request 120 to fare processing system 300, which respondswith authorization response 130, generated by contained bankcardverification proxy 610. In response, fare processing system 300 sendsauthorization request 140, also generated by contained bankcardverification proxy 610, to bankcard verification system 600, whichresponds with authorization response 150.

FIG. 12 shows a bankcard verification proxy 610 being used only for somecard networks, in accordance with some instances of the presentinvention. For this, it either is deployed between switch 640-3 and cardnetwork 650-1 (as shown) or, alternatively, bankcard verification proxy610 may, regardless of its logical location, selectively passauthorization requests 120 upstream based on criteria that include thecard network. In the configuration shown in FIG. 12, authorizationrequest 120 is routed by switch 640-3 to the appropriate card network650. Requests destined for card network 650-1 are passed on to bankcardverification proxy 610, while requests destined for card network 650-2are not intercepted by a proxy and are always processed directly by thatcard network, which responds with authorization response 150 that isthen routed to the originator of the corresponding authorization request120, whereas authorization requests 120 that are destined for cardnetwork 650-1 are intercepted, and may be responded to, by bankcardverification proxy 610. As in FIG. 7, the boundary between transitauthority and financial network in FIG. 12 indicates the preferredgeographical location, which may differ from operational and legalboundaries.

FIG. 13 depicts a bankcard verification proxy 610 and fare processingsystem 300 draw upon access control lists (ACL) that are maintained byinterpreting data from various sources, according to some embodiments ofthe present invention. In some instances, transit account ACL 230A ismaintained by fare processing system 300 by incorporating informationabout registered bankcards 180 from transit registration system 500,which, in some instances of the invention, uses a bankcard verificationsystem 600 to authenticate and/or authorize bankcards duringregistration. In some instances of the invention, transit account ACL230A is maintained by interpreting authorization response 140 and/orsettlement response 160 received from bankcard verification system 600in response to authorization request 120. In some instances of theinvention, transit account ACL 230A is maintained by interpretingbankcard data 110 and/or bankcard authorization request 120 as receivedfrom bankcard terminal 200. In some instances of the invention, transitaccount ACL 230A is manipulated directly at terminal 360 via directentry data 195. In some instances, transit account ACL 230A ismaintained by interpreting list updates 190 derived from bankcard ACL230B. In some instances of the invention, transit account ACL 230A isreplicated, in whole or in part, on Bankcard Terminal 200. In otherinstances of the invention, transit account ACL 230A is maintainedentirely on one or more instances of Bankcard Terminal 200.

Likewise, in some instances of the invention, bankcard ACL 230B ismaintained by interpreting list updates 190 derived from transit accountACL 230A. In some instances of the invention, bankcard ACL 230B ismanipulated directly at terminal 360 via direct entry data 195. In someinstances of the invention, bankcard ACL 230B is maintained byinterpreting known good and/or known bad data 170 received via bankcardverification system 600, for example a list of stolen or lost cards. Insome instances of the invention, bankcard ACL 230B is maintained byinterpreting authorization response 140 and/or settlement response 160received from bankcard verification system 600 in response toauthorization request 120. In some instances of the invention, bankcardACL 230B is replicated, in whole or in part, on Bankcard Terminal 200,even if the configuration differs from FIG. 10. In other instances ofthe invention, bankcard ACL 230B is maintained entirely on one or moreinstances of Bankcard Terminal 200, even if the configuration differsfrom FIG. 10. In some instances of the invention, as described above andindicated in FIG. 11, transit account ACL 230A and bankcard ACL 230B areboth maintained by fare processing system 300.

FIG. 14 details a transit account ACL 230A containing transit accountrecord 700, according to some instances of the present invention. Atransit account record may reference: (1) list of tokens 710 of one ormore tokens (whereas a token is anything a rider may present to the gateto authenticate themselves) and their status (e.g., valid/invalid); (2)list 720 of at least one method of billing, including bankcards, whereaseach bankcard may also be a token, so that list of tokens 710 and list720 may in some instances of the invention be one and the same; (3)optionally list 730 of fare products, such as a monthly pass including:(4) details 740 for fare products if required; and (5) collection statusof account. The collection status may be stored indirectly by storingand maintaining one or more balances.

FIG. 15 details a bankcard ACL 230B containing a bankcard record 760. Abankcard record references bankcard details 770, such as the card's PAN,the imprinted name, expiration date. In some instances of the invention,bankcard details 770 include additional data, such as the associatedbilling address, a cryptographic hash or secondary card details, such asan RF fingerprint of the card or the manufacturer of the card'scircuitry. A bankcard record 760 additionally contains bankcard status780, such as reference to historical data or a flag, such as ablack/white flag.

FIGS. 16A and 16B show the invention's response to a presented usertoken 105, according to some embodiments of the present invention. Twopresented user tokens 105 (e.g., a government ID or a biometric handscan) may differ based on user token 105 being a determined to be aknown valid user token or being a presently unknown or black listed(i.e., known invalid) user token. FIG. 17 shows the response to apresently unknown or black listed user token. The response to a knownvalid user token is shown in FIG. 20.

The invention's response to a presented bankcard 100 differs, as shownin FIG. 16B, based on bankcard 100 either being determined to be a knownvalid bankcard or as a presently unknown or black listed (i.e., knowninvalid) bankcard. The response to a known valid bankcard is shown inFIG. 19. Responses to a presently unknown or black listed bankcard areshown in FIGS. 18A through 18C.

FIG. 17 shows the response to an unregistered user token 105, asindicated above, is shown in FIG. 17: non-bankcard bankcard data 110,relating to user token 105, is received by bankcard terminal 200 inresponse to the presentation of user token 105. Bankcard terminal 200passes on the non-bankcard bankcard data 110 (or data derived from it)to fare processing system 300, which makes a determination based ontransit account ACL 230A, specifically by examining the list of one ormore lists of tokens 710 for the existence and status of user token 105.After user token 105 is determined to be an unknown non-bankcard usertoken 800 (i.e., it is not listed in transit account ACL 230A) ordetermined to be invalid (i.e., it is listed on transit account ACL 230Aas invalid), negative authorization response 150 is returned to bankcardterminal 200, which, for example, signal this result by lighting up ano-entry sign at a turnstile. FIG. 17 is specific to a configuration ofthe invention, where transit account ACL 230A is not replicated in wholeor in part to bankcard terminal 200. In a configuration where the ACL230A is replicated in whole or in part to bankcard terminal 200, thedetermination can be arrived at without contacting fare processingsystem 300.

FIGS. 18A, 18B and 18C show the response to the presentation of anunknown or black listed bankcard 100, as implemented in some embodimentsof the invention. In FIG. 18A, Bankcard data 110, relating to bankcard100, is received by bankcard terminal 200 in response to thepresentation of bankcard 100. Bankcard terminal 200 passes on thebankcard data 110 (or data derived from it) to fare processing system300, which makes a determination based on transit account ACL 230A,specifically by examining the list of one or more tokens 710 for theexistence and status of bankcard 100. In response to determiningbankcard 100 to be an unknown bankcard 810 (i.e., it is not listed intransit account ACL 230A) or to be invalid (i.e., it is listed ontransit account ACL 230A as invalid), an authorization request 120 isreceived by bankcard verification proxy 610.

FIG. 21 shows the sequence of events making up a transfer transaction,where a plurality of rides are accounted for as a single ride: when therider presents their bankcard 100 or other identifying token 105,bankcard data 110 (or other identifying data indicative of the presentedcard or token) are transmitted to terminal 200. Terminal 200 passes thedata (or data derived from it) on to fare processor 300. If fareprocessor 300 determines the eligibility of the ride as a transfer(e.g., by searching a historical database for transactions involving abankcard or other identifying token associated with the same rider), anauthorization 150 is immediately granted. In that process, bankcardverification proxy 610 is not required, and neither is the bankcardverification system 600—i.e. the transfer transaction occurs within themass transit domain and not within the financial network domain.

FIGS. 22A and 22B show two alternative reactions when fare processor 300determines (880) that it cannot communicate with either the bankcardverification system 600 nor proxy 610: FIG. 22A shows an embodimentwhere fare processor 300 gives authorization for any card or tokendetermined to be unknown (810) and simply accounts for it (890) in thehopes of later being able to collect. FIG. 22B shows an embodiment whereall unknown cards are rejected when communications with neither bankcardverification system 600 nor proxy 610 are possible.

FIGS. 23A and 23B show two decision trees, implemented in someembodiments of the present invention, the distinction being that FIG.23A is for a bankcard 100, which is not only an identification token,but also a financial instrument, whereas FIG. 23B is for identificationtokens that are not a financial instrument or inherently coupled to one:in both cases, fare processor 300 determines (1010) whether it has arecord of the bankcard or token, respectively. If an unknown bankcard ispresented, its characteristics as a financial instrument allow for it tobe established ad hoc as a known bankcard. Contrarily, an unknownidentification token, results in a denial of access (1060).

FIG. 24 shows how the fare processor 300 settles balances of transitaccounts it maintains (a transit account, in some embodiments, can be assimple as the record of a single bankcard, but in other embodiments canencompass records of a plurality of identifying tokens and/or aplurality of records of settlement accounts): when the decision tosettle (1010) is made by fare processor 300, bankcard infrastructure 600is used to issue payment request 1020. In response to an acknowledgingresponse 1030, fare processor 300 may change the recorded state of theaccount (or, in the simpler case, the card) from known invalid (e.g.,due to payment overdue) to known valid. In response to an negative(NACK) response 1030, fare processor 300 may change the recorded stateof the account/card from known valid to known invalid.

FIGS. 25 and 27 represent flowchart implementations for operations in aprocessing system, in accordance with embodiments of the presentinvention. In FIG. 25, at 411, fare processing system 300 attemptssettlement, for example, to collect for monthly charges. At 412, adetermination is made whether the attempt was successful. At 413, if theattempt was unsuccessful, the set of bankcard records 230 may be updatedto indicate the bankcard is now invalid. At 414, if the attempt wassuccessful, the set of bankcard records 230 may be updated to indicatethe bankcard is valid. At 415, if changes are made to the set ofbankcard records 230, an update may be provided to each bankcardterminal. The update may be provided as a new set of bankcard records230 that the bankcard terminal will use as a replacement set.Alternatively, the update may be provided as incremental changes to theexisting set.

FIG. 26 illustrates the process of registering a token and paymentmethod for a fare product (token and payment method can be the same, asin the case of a bankcard 100, or different, e.g., an RFID fob asidentification token 105 and an employee benefit account as paymentmethod): registration system 500 (e.g, a web server, or a issuanceserver at a bank) transmits registration data 185 to fare processingsystem 300, which, in the scenario depicted, determines (810) thepayment method to be, as shown here, in the case of a bankcard, an“unknown bankcard”. In case of other payment methods, analogous statesexist. The payment method is then validated, in the case of a bankcard,by transmitting an authorization request 120. If the bankcardverification proxy 610 also determines (820) the bankcard to be unknown,an authorization request 140 is transmitted to bankcard verificationsystem 600, which responds with authorization response 150. In the caseof positive acknowledgement (as shown), bankcard verification proxy 610updates its records to indicate that the card is now a known card andsends an authorization response 150 to fare processor 300. In response,fare processor 300 will grant the entitlement by updating its accesscontrol lists accordingly. Optionally, authorization response 150 isforwarded to registration system to allow for feedback at registrationsystem 500.

FIGS. 27, at 421 to 428, shows a process to register bankcards with aback-end through a web interface, kiosk, telephone or other interactivesystem such as used by a financial institution. Through the registrationprocess, a fare processing system 300 associated with a set of transitsystems including at least one transit system maintains a set ofbankcard records.

At 421, a fare processing system 300 receives, from a bankcardregistration system through its third interface 350 to the registrationsystem, a registration request. The registration request is a request bythe remote bankcard holder or by a financial institution or its agent toregister the bankcard with the fare processing system 300. Bypre-registering the bankcard, future regulation of entry or access toany of the set of transit systems may be more quickly performed, forexample, because a remote bankcard terminal 200 will not need to performan authorization or clearing and settlement request with a distantbankcard verification or clearing and settlement system. Theregistration request contains bankcard data of a bankcard presented by arespective holder of the bankcard. The bankcard data may include anidentifier of the bankcard such as the PAN or credit card number. Next,the fare processing system 300 determines an identifier of the presentedbankcard. This determined identifier of the presented bankcard may beused as an index to a database or lookup table and may be a PAN or acredit card number or derived from the PAN or credit card number such asthrough a hashing function.

At 422, the fare processing system 300 determines whether the determinedidentifier is contained in a set of bankcard records. The set ofbankcard records includes identifying information of bankcards that werepreviously presented to the fare processing system 300. These previouslypresented bankcards include bankcards from a plurality of issuers. Forexample, the set contains at least one bankcard from a first issuer(e.g., Chase®) and at least one bankcard from a second issuer (e.g.,American Express®). The plurality of issuers may contain two or moreissuers including, for example, Chase, American Express, Citi®, Bank ofAmerica®, Discover®, MasterCard®, Visa® and the like. The set contains anumber of values for each bankcard including an identifier of a bankcardpreviously presented to the processing system. This identifier in theset may be searchable and may be used by the fare processing system 300when determining whether the determined identifier is contained in a setof bankcard records.

At 423, the fare processing system 300 attempts to verify the bankcardthrough a bankcard verification system. The attempt to verify thecurrently presented bankcard with the bankcard verification system mayinclude attempting to verify the currently presented bankcard with aclearing and settlement network. Alternatively, the attempt to verifythe currently presented bankcard with the bankcard verification systemmay include receiving an authorization, from a clearing and settlementnetwork, for an amount of funds from an account linked to the currentlypresented bankcard. In some circumstances, the attempt to verify thecurrently presented bankcard with the bankcard verification system mayresult in a failed attempt. For example, the attempt to verify thecurrently presented bankcard with the bankcard verification system mayresult in receiving, from the bankcard verification system, anindication that the bankcard verification system rejects theauthorization of a financial charge.

By verifying the bankcard, the fare processing system 300 determineswhether the bankcard will be eligible or ineligible for a futurepurchase. At 424, if the verification is not successful, the fareprocessing system 300 reports this failure at 425. That is, the fareprocessing system 300 reports a failure, if attempting to verify thepresented bankcard results in a determination of an invalid bankcard. At426, if the set contains invalid or ineligible bankcards, the fareprocessing system 300 changes the set to show that the bankcard is aninvalid bankcard. That is, the fare processing system 300 removes, fromthe set of bankcard records, the present bankcard, if attempting toverify the presented bankcard results in the determination of an invalidbankcard. At 424, if the verification is successful, the fare processingsystem 300 changes the set to show that the bankcard is a valid bankcardat 427. That is, the fare processing system 300 incorporates thepresented bankcard into the set of bankcard records, if attempting toverify the presented bankcard with the bankcard verification systemresults in receiving an indication of a valid bankcard.

In either case at 428, if the fare processing system 300 made a changeto the set of bankcard records, it will communicate, to at least onebankcard terminal 200, updates to the set of bankcard records. Theupdates may be made either individual for each received bankcard recordor may be aggregated as a batch update. The update may be downloaded toa bankcard terminal 200 by an electronic data connection or may be madeby physically porting a memory device (e.g., a CD-ROM or flash drive)from the fare processing system 300 to the bankcard terminals 200.

In some embodiments, the set of bankcard records 230 contains onlybankcards presented to the system at the front-end through bankcardterminal. In other embodiments, the set of bankcard records 230 containsonly bankcards presented to the system at the back-end through aregistration system. Still in other embodiments, the set of bankcardrecords 230 contains only bankcards presented to the system at eitherthe front-end or the back-end. In some embodiments, the set of bankcardrecords 230 contains only bankcards individually by a holder of thebankcard. In some embodiments, the set of bankcard records 230 containsonly bankcards individually by a holder or holder's agent of thebankcard. In a sense, each of the presentations is learned by thesystem. In some embodiments, the set of bankcard records 230 includesbankcards presented by a financial institution, or the like, in additionto the learned bankcards.

A rules processor may be used to process bankcard records or user tokendata. These presentations may be processed offsite in real-time oroffline individually or accumulated and processed in a batch mode. Insome embodiments, a bankcard is either a debit card or a credit card. Inother embodiments, a user token or identifying toke is used. Anidentifying token may be a bankcard or other payment card or otheridentification (ID) card or chip in the form of a card or embedded in oron another device such as a mobile phone.

When bankcard presentations are processed offline (not in real-time),resulting user toke records, each representing a presentation, may bereceived by a rules processor in non-sequential order. That is, recordsmay be received out of order and perhaps some records may be delayed bya substantial period of time.

FIG. 28 shows additional detail of a presentation record processor(rules processor) 300, in accordance with embodiments of the presentinvention. The fare processing system 300 may comprise a processor 301coupled a first interface (communication interface 304, which may be aTCP/IP interface, a socket or a computer bus) to accept user tokenrecords 1103 and a second interface (communication interface 305, whichmay similarly be a TCP/IP interface, a socket or a computer bus) to sendsettlement transaction data 1005. The processor 301 is also coupled to acache 302, a main memory 303 and one or more databases 306. Two or moreof the components described in FIG. 28 may be incorporated in to anintegrated device.

Therefore, it should be understood that the invention can be practicedwith modification and alteration within the spirit and scope of theappended claims. The description is not intended to be exhaustive or tolimit the invention to the precise form disclosed. It should beunderstood that the invention can be practiced with modification andalteration.

1. A method for gating entry into a first transit system, the method comprising: receiving a set of records, wherein each includes an index representative of an individual token, and wherein the set of records includes a set of records representing black-listed tokens wherein a black-listed token will be denied access to the first transit system; sequentially reading, at a token terminal, and processing token data from a plurality of tokens, wherein a first token of the plurality of tokens is issued by a first issuer and a second token of the plurality of tokens is issued by a second issuer separate and distinct from the first issuer, and wherein the first issuer and the second issuer are separate from the first transit system; processing a third token comprising: (a) reading, at the token terminal, token data from the third token; (b) determining an index representative of the third token; (c) searching for the index representative of the third token in the set of records to determine a status of the third token; (d) setting the status of the third token to indicate the third token is an unknown token; and (e) allowing access into the first transit system and entering, to a transaction history database, an indication of access into the first transit system by a holder of the third token; providing, to a processing system, entries from the transaction history database for remote determination of a transaction amount for each entry; and receiving an update to the set of records.
 2. A method for authorizing a bankcard transaction, the method comprising: downloading two sets of records comprising a first set of records and a second set of records, each comprising at least a bankcard identifier, the first set of records representing known invalid bankcards, and the second set of records representing known valid bankcards; receiving a first authorization request, referencing a first bankcard; checking if the first bankcard matches a known invalid card; denying the first authorization request, if the first bankcard matches the known invalid card; receiving a second authorization request, referencing a second bankcard, the second authorization request comprising at least the bankcard identifier of the second bankcard; checking if the second bankcard matches the known invalid card or the known valid card; and approving the second authorization request, if the first bankcard does not match any known invalid cards, and matches a known valid card.
 3. The method of claim 2, wherein the first authorization request and second authorization request respectively comprises at least the bankcard identifier of the first bankcard and the second bankcard.
 4. The method of claim 2, wherein the first authorization request and second authorization request respectively comprises bankcard data.
 5. The method of claim 2, wherein the first set of records is published by at least one card network.
 6. The method of claim 2, wherein the first set of records is published by a transit processor.
 7. The method of claim 6, wherein the second set of records is published by a transit processor.
 8. The method of claim 6, wherein the second set of records is published by a bankcard issuer.
 9. The method of claim 6, wherein the second set of records comprises an indication of a range of bankcards.
 10. The method of claim 2, wherein the first set of records is derived from successful bankcard registrations.
 11. The method of claim 2, wherein the act of downloading two sets of records comprises downloading a single set of records together with an indication as to which records designate known invalid cards and which records designate known valid cards.
 12. The method of claim 2, wherein the act of downloading two sets of records comprises downloading a first set of records and separately downloading a second set of records.
 13. The method of claim 2, further comprising merging the first set of records and the second set of records into a single set of records.
 14. The method of claim 2, wherein the first set of records and the second set of records are merged with an existing set of records.
 15. The method of claim 2, wherein each act of checking comprises an inquiry into a merged set of records.
 16. The method of claim 2, wherein the first authorization request and second authorization request are made by a fare processor.
 17. The method of claim 16, wherein the fare processor issues the first authorization request and second authorization request in response to a bankcard presentation at a bankcard reader, coupled to the fare processor.
 18. The method of claim 17, wherein the bankcard reader is located in a public transit system.
 19. The method of claim 2, wherein the second authorization request is made in response to bankcard presentation at a registration system.
 20. The method of claim 2, further comprising: receiving a third authorization request, referencing a third bankcard; checking if the third bankcard matches the known invalid card; checking if the third bankcard matches a known valid card; using information about the third bankcard as an input to an authorization function; and approving the third authorization request based on a result of the authorization function, if the third bankcard does not match any known invalid cards and does not match a known valid card.
 21. A method for controlling access to a transit network by maintaining a black list of identifying tokens, the method comprising: granting a potential rider access to a transit system upon presentation of an identifying token, comprising: reading a first set of token data from a first identifying token using a token reader; computing a first token identifier from token data; checking a first token against a black list in memory, using the first token identifier; and allowing access to the transit network, if the first token is not black listed; denying a potential rider access to the transit system upon presentation of an identifying token, comprising reading a second set of token data from a second identifying token, using a token reader; computing a second token identifier from the token data; checking the second token identifier against the black list in memory, using the second token identifier; and denying access to the transit network, if the second token is black listed; removing a third identifying token from the black list after its outstanding balance is paid, comprising: successfully charging a payment account associated with the third identifying token; and removing the third identifying token from the black list; and adding a fourth identifying token to the black list if the outstanding balance remains unpaid, comprising: unsuccessfully charging one or more a payment accounts associated with the fourth identifying token; and adding the fourth identifying token to the black list.
 22. The method of claim 21, wherein the act of computing a token identifier from the token data comprises applying of a hash function.
 23. The method of claim 21, wherein at least one of the first identifying token, second identifying token and third identifying token is a bankcard.
 24. The method of claim 21, wherein the token data is bankcard data.
 25. The method of claim 21, wherein the act of computing a token identifier from the token data comprises extraction of a Primary Account Identifier.
 26. The method of claim 21, wherein the black list is a uniquely identifiable subset of a larger set of identification token data.
 27. A fare processing system associated with a set of public transit systems, the fare processing system comprising: a first interface to receive a plurality of presentation records from at least one of the set of public transit systems; record memory to hold received presentation records; rule memory to hold fare rules; account memory to store a state of one or more transit accounts; a second interface connected to a payment gateway to settle the one or more transit accounts; and one or more processors, coupled to the first interface and second interface and to the record memory, the rule memory and the account memory, to apply the fare rules held in the rule memory to presentations records held in presentation record memory.
 28. The fare processing system of claim 27, wherein the presentation records are derived from bankcard data.
 29. The fare processing system of claim 27, wherein the first interface is a TCP/IP socket.
 30. The fare processing system of claim 27, wherein the first interface is a serial transceiver.
 31. The fare processing system of claim 27, wherein the record memory is a database.
 32. The fare processing system of claim 27, wherein the rule memory is a rule base.
 33. The fare processing system of claim 27, wherein the rule memory is RAM containing machine readable instructions.
 34. The fare processing system of claim 27, wherein coupling between the one or more processors and the rule memory is a computer bus.
 35. The fare processing system of claim 27, wherein coupling between the one or more processors and the record memory is a socket.
 36. The fare processing system of claim 27, wherein the second interface is a computer bus.
 37. The fare processing system of claim 27, wherein the record memory and the rule memory share a same physical memory and a distinction between the record memory and the rule memory is through a data structure.
 38. The fare processing system of claim 27, wherein the fare processing system interfaces indirectly with gates.
 39. The fare processing system of claim 27, wherein the fare processing system interfaces directly with gates. 